A device of this type is known, for example, by the trade name “safepad.”
In the context of the invention, the term “terminal” should be understood in a general sense. The aforementioned terminal can specifically be constituted by a personal computer running on various operating systems, such as WINDOWS or UNIX (both of which are registered trademarks). It can also be constituted by a workstation, a portable computer or a so-called dedicated card terminal.
Likewise, in the context of the invention, the term “internet network” includes, in addition to the Internet per se, private enterprise networks or the like, known as “intranets,” and the networks that extend them to the outside, known as “extranets.”
Smart cards are used in various fields: banking and health care applications, as so-called electronic “purses,” etc. Moreover, several applications can coexist in a smart card (a multi-application smart card).
For these types of applications, smart cards can be assigned various functions. In particular, they can be used for security purposes. The term “security” should be understood in a general sense, including confidentiality and/or the authentication of the user of the station and/or the holder of the smart card itself.
In the more specific context of these applications, the terminal can be equipped with a secure enclosure comprising a smart card reader, a keyboard and possibly one or more other computing resources.
FIG. 1 schematically illustrates the architecture of a terminal of the aforementioned type, according to the prior art.
To illustrate the concepts, it is assumed that the terminal 1 is basically constituted by a microcomputer. It is equipped with all the usual devices constituting such computing equipment and required for their proper operation (which are not represented): central processor, RAM, mass storage (hard disk), reader(s) information media (diskettes, etc.). In the particular case illustrated in FIG. 1, the terminal 1 is equipped with a secure enclosure 3 comprising a smart card 2 reader 30 and a keyboard 31. The keyboard 31 is specifically used to enter data for authenticating the holder of the smart card 2: for example a password associated with an identifier of the smart card 2. Various electronic circuits allow communication between the secure elements present inside this enclosure, including the keyboard 31 and the smart card 2 (via the reader 30), and between these secure elements and the non-secure elements present in the terminal 1.
Normally, the terminal comprises, in its non-secure part, a specific application 10, which will be hereinafter be called a “merchant” application, which handles the management and control of specific transactions permitted by the terminal 1 in question. Communications between this application 10 and the elements inside the secure enclosure 3 normally take place in accordance with a standard of the RS232 type. Communications between the elements inside the secure enclosure 3, including a resident application 300, and the smart card 2, via the reader 3, normally take place in accordance with a protocol that complies with the ISO standards 7816-1 through 7816-4.
This type of architecture specifically has the following primary drawbacks:
the merchant application installed in the terminal (non-secure part) and that residing in the secure enclosure are specific to this terminal;
the associated computer programs are generally voluminous; and
flexibility and reliability are limited, since any modification of these programs requires a reloading of programs into the terminal (non-secure part) and into the secure enclosure, and thus possibly the execution of functional tests, which requires the presence of specialized personnel.
Generally, the latter operation must be repeated for a large number of terminals.
It must also be kept in mind that these applications must be fully or partially secure. It is therefore necessary to be able to guarantee, for the updating of the programs, a given level of security, appropriate for the specific application.
Most often, the terminal 1 is not isolated, in the sense that it is linked via a transmission network RI to one or more remote systems, one of which 4 is illustrated in FIG. 1. The nature of the network RI can vary, depending on the applications envisaged (banking, health care, etc.). It could be the Internet or a network of that type (intranet or extranet), given the rapid growth of the latter type of network and the applications that use it. Normally, the overall architecture is of the so-called “client-server” type, the “server” generally being the remote system 4 and the “client” being the terminal 1. But under certain circumstances, the roles may be reversed or alternated during the time of a transaction.
In an architecture of this type, the programs associated with the specific application 10 and the application 300, during a modification of their version for any reason whatsoever, can be updated in a centralized way, from one of the remote servers, for example the server 4. It follows that one of the drawbacks indicated can be alleviated, the update being performed by downloading. These operations, however, require the implementation of administrative procedures that are well known. Moreover, the download can include sensitive data, or at least should not allow the installation into the terminal of programs and/or procedures that are unauthorized or dangerous for security (a “Trojan horse,” “logical bombs,” viruses, etc.).
Furthermore, with the increase in power and the universality of the Internet, there is a need to make the aforementioned specific applications, installed locally in the terminals, “migrate” to the remote servers, which will hereinafter be called “merchant servers,” and to dialog directly with the smart card from these merchant servers.
This second need, in particular, cannot be satisfied by the terminals of the prior art, for reasons that will be explained below.
But first, it seems useful to briefly describe a system architecture that allows communication between a terminal according to the prior art and a remote server, via an internet network RI. An architecture of this type is represented schematically in FIG. 2, a figure in which the logical architecture of the terminal, references 1′, is more particularly represented.
The terminal 1′in this case is a general type of terminal which may or may not be secure, this characteristic being unimportant for explaining the various types of communication in question.
As indicated above, the terminal 1′ naturally includes all the circuits and devices required for its proper operation, which are not represented in order to simplify the drawing. Normally, the terminal 1′ is also connected to standard peripherals, which may or may not be integrated, such as a display screen (not represented) and a keyboard 31, located in a secure enclosure (FIG. 1: 3) in the particular context of the invention.
Normally, communications in networks take place in accordance with protocols that comply with standards comprising several superposed software layers. In the case of an internet network RI, communications take place in accordance with protocols that are specific to this type of communication, but that also comprise several software layers. The communication protocol is chosen based on the application specifically envisaged: web page consultation, file transfers, e-mail, forms or news, etc.
The architecture of communication networks is described by various layers. For example, the OSI (“Open Systems Interconnection”) standard defined by the ISO includes seven layers, which run from the so-called lower layers (for example the so-called “physical” layer that concerns the physical transmission medium) to the so-called upper layers (for example the so-called “application” layer), passing through intermediate layers, including the so-called “transport” layer. A given layer offers services to the layer that is immediately above it and requires other services from the layer that is immediately below it, via appropriate interfaces. The layers communicate by means of primitives. They can also communicate with layers on the same level. In certain architectures, one or another of these layers may be nonexistent.
In an Internet environment, there are five layers, and more precisely, going from the top layer to the bottom layer: the applications layer (http, ftp, email, etc.), the transport layer (TCP), the network address layer (IP), the data link layer (PPP, Slip, etc.) and the physical layer.
The terminal 1′ includes circuits 11 for accessing the internet network. This could be a modem for connecting to a switched telephone line or an integrated services digital network (ISDN), for example via an Internet service provider (or ISP). The circuits 11 for accessing the network RI contain the lower software layers C1 and C2, which correspond to the aforementioned physical and data link layers.
Also represented are the upper layers C3 and C4, which correspond to the “network address” (IP) and “transport” (TCP) layers. The upper application layer (http, ftp, email, etc.) is represented schematically by a web browser NW of any type, preferably a standard type on the market.
The interface between the lower layers C1 and C2 and the upper layers C3 and C4 is constituted by a software layer 15, generally called a “lower level driver.” The upper layers C3 and C4 are supported by this interface and are implemented by means of libraries of specific functions, or network libraries 14, with which they correspond. In the case of the Internet, TCP/IP is implemented by means of libraries called “sockets.”
This organization allows the browser NW to present requests to a remote server 4, in order to consult web pages (HTTP protocol), transfer files (FTP protocol), or send email (email protocol).
The terminal 1′ also includes the card reader 30, located in a secure enclosure (FIG. 1: 3) in the particular context of the invention. To communicate with the smart card 2, the card reader 30 also includes two lower layers CC1 (physical layer) and CC2 (data link layer), which play a role similar to the layers C1 and C2. The software interfaces with the layers CC1 and CC2 are described, for example, by the PC/SC specification (“Part 6, Service Provider”). The layers CC1 and CC2 themselves are specifically described by the ISO standards 7816-1 through 7816-4.
An additional software layer 13 forms an interface between application layers, under the single reference Appli1, and the lower layers CC1 and CC2. The chief function devolved to this layer 13 is a multiplexing/demultiplexing function.
On the smart card 2 end, there is a similar organization, i.e., the presence of two lower layers, referenced CC′1 (physical layer) and CC′2 (data link layer), as well as an interface layer 23, entirely similar to the layer 13. This layer 23 provides an interface between the aforementioned protocol layers CC′1 and CC′2 and one or more application layers, represented in the form of a single module referenced Appli2.
Communications between the smart card reader 30 and the smart card 2 take place by means of standard commands, known by the abbreviation APDU, for “Application Protocol Data Unit”).
Various protocols can be used, including as non-exhaustive examples the following:
the ETSI GSM 11.11 recommendation;
the protocol defined by the ISO 7816-3 standard, in character mode T=0;
the protocol defined by the ISO 7816-3 standard, in block mode T=1;
or the protocol defined by the ISO 3309 standard, in HDLC (for High-Level Data Link Control procedure) frame mode.
Within the scope of the invention, the ISO 7816-3 protocol is preferably used, in block mode.
In an intrinsically known way, each protocol layer is associated with a certain number of primitives that allow data exchanges between layers of the same level and from one layer to another.
In the current state of the art, it is not possible to place the smart card in direct communication with a remote server 4 via the Internet RI, since the communication protocol with a standard type of smart card 2, as indicated above, is incompatible with those used in the Internet or in any network of this type. Nor is it possible to establish direct communications between the browser NW and the smart card 2, except by installing in the browser NW a piece of software, called a “plug-in,” of a specific type.
Referring again to FIG. 1, assuming that the terminal 1 is linked to the Internet, and to summarize what has been mentioned above, it is noted that this terminal 1 according to the prior art, comprising a secure enclosure 3 equipped with a keyboard 31 and a smart card 2 reader 30, includes two main communication interfaces, S1 and S2, represented in dotted lines. A first interface S1 links the enclosure 3 to the terminal 1 per se in which the merchant application 10 is run, and a second interface S2 is provided for communications with the smart card 2. In reality, the interface S2 is distributed between the application 300 and the smart card 2. Added to both of these interfaces is the interface to the outside (FIG. 2: particularly the circuits 11), which allows the terminal 1 to communicate with the internet network RI. The interface S1 accepts two levels of dialogue: a first, transparent dialogue for which a command sent by the terminal 1 is executed without semantic modification by the interface S2, and a second level of dialogue that involves the application 300.
Thus, the authentication by entering a password on the keyboard 31 is a command submitted to the interface S1 that is interpreted by the application 300 and transformed into a series of exchanges via the interface S2 between the application 300 and the smart card 2. The result of these exchanges is transmitted to the interface S1.
Other than the fact that it is impossible, in the current state of the art, for a standard smart card 2 to accept direct exchanges with the Internet RI, as indicated above, the major drawback of the terminals according to the prior art is constituted by the presence of the resident application 300. It is most often a so-called “proprietary” application, which means that the merchant application 10 must be written based on the characteristics and the type of the terminal used. It is therefore a priori different from one type of terminal to another, which does not facilitate maintenance operations. Moreover, it is not adapted to an Internet type of environment.
Standards have been proposed for applications of the same type as the invention, such as the standard known by the abbreviation OCF (for “Open Card Framework”), which attempts to standardize exchanges between the merchant terminal 1 and the smart card 2 reader 30 in compliance with, for example, the EMV standard for terminals. However, such a standard is not directly usable in an internet context.
There is also the so-called “C-SET” protocol, known in the field of banking applications defined by the GIE bank card. Using this protocol, a user connects to a merchant site available on the web and makes a purchase. During the transaction, the latter accesses elements of the secure enclosure in order to authenticate the holder of the bank card making the purchase. This authentication is performed by running software in the terminal (non-secure part) and the enclosure.
This protocol is not free of drawbacks, either:
it requires the presence of specific software in the terminal and in the enclosure;
it requires the certification of the software required by C-SET;
the C-SET protocol is payment-oriented only; the software in the terminal that processes the information from the web server and from the bank card payment is payment software.
In these characteristics, it does not differ much from the solutions of the prior art mentioned above. It does not allow end-to-end communications using an Internet protocol, including direct addressing of the smart card. Given its specificity, it offers no flexibility and is not adapted for use in other fields: health care, updating of data stored in a smart card, point crediting, etc